home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 3⁄9⁄90 / 0837-Re[3] Model⁄View…-Mar90 < prev    next >
Encoding:
Text File  |  1990-03-09  |  1.7 KB  |  47 lines  |  [TEXT/GEOL]
  1. Item    3457257                         7-March-90        18:44PST
  2.  
  3. From:   POWERUP.DEV                     Power Up Software,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.         ALGER                           Alger, Jeff,VCA
  7.  
  8. Sub:    Re- Re- Re- Model/View…
  9.  
  10. Attn:  MacApp.Tech$
  11. Attn: Alger, Jeff,VCA
  12. SentBy: James Plamondon
  13. Date   3/7/90
  14. Subject    Re- Re- Re- Model/View…
  15. From   James Plamondon
  16. To Alger, Jeff,VCA
  17. CC  MacApp.Tech$
  18.  
  19. Reply to:  Re: Re: Re: Model/View…
  20. Jeff,
  21.  
  22. OK, the TPublisher/TSubscriber mechanism sounds reasonsble.  (I still like the
  23. Supporter and Dependent terminology better, but — what the heck.)  I have a
  24. couple of questions left, though.
  25.  
  26. I am afraid that I don't understand the advantage of having new classes stuck
  27. into the hierarchy over modifying the MacApp source directly.  MacApp source
  28. isn't sacred.  Rather than trying to wedge TSubscriber between TObject and
  29. TEventHandler, why not just add the necessary code to TEventHandler and punt
  30. the whole problem?  Perhaps I'm missing something here.
  31.  
  32. Likewise, the separation of TSubscriber and TPublisher into separate classes
  33. enforces what I cannot help but think is an unnecessary restriction:  that a
  34. publisher cannot be a subscriber, and vice versa.  By adding both the
  35. TPublisher and TSubscriber code directly to TObject, any object can then be
  36. either a publisher or a subscriber — or both.  The only added overhead that I
  37. can see is in  1) bigger TObject method tables, and  2) the global dependency
  38. dictionary.
  39.  
  40. Is there something specifically wrong or inadequate in this more general
  41. mechanism that would make it either impossible or inappropriate to implement?
  42.  
  43. Looking forward to your response, I remain
  44.  
  45. James Plamondon
  46.  
  47.